home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / lang / c-part1 / 7412 < prev    next >
Encoding:
Internet Message Format  |  1996-08-05  |  3.5 KB
  1. Path: gail.ripco.com!mambuhl
  2. From: mambuhl@ripco.com (Martin Ambuhl)
  3. Newsgroups: comp.lang.c
  4. Subject: Re: Universal include fil
  5. Date: 26 Feb 1996 07:18:06 GMT
  6. Organization: Ripco Communications, Inc.
  7. Message-ID: <4grmre$3uu@gail.ripco.com>
  8. NNTP-Posting-Host: foley.ripco.com
  9.  
  10. pahint@eunet.be (Pieter Hintjens)
  11. in <4gnjea$30m@news.Belgium.EU.net> writes:
  12.  
  13. >I am working on a project to build a 'Universal Include File'.
  14. >The point is to encapsulate the peculiarities of every system
  15. >under the sun into one include file.  Maybe this is not doable,
  16. >but I already have something halfway decent.
  17.  
  18. >The UIF should include all the standard header files: certainly
  19. >all those defined in the ANSI C standard, plus those that are
  20. >common enough to be valuable.  (E.g. socket interface files.)
  21.  
  22. A few comments here:
  23. There is no conditional for the following
  24. >#include <fcntl.h>
  25. even though it is clearly _not_ a standard header.
  26. Since the other 9 headers in this group are standard headers,
  27. and since fcntl.h is not guaranteed to be present, I suggest
  28. a test for the implementation.
  29.  
  30. The failure to include locale.h, iso646.h, wctype.h, and wchar.h is
  31. perhaps understandable, since many implementations will not have the
  32. last three (Amendment 1) headers and these 4 are of limited use to many
  33. programmers.  I am a little suprised that this should be true for you as
  34. a .be domain programmer.
  35.  
  36. However, I find the failure to include the standard headers assert.h,
  37. float.h, math.h, setjmp.h, and stddef.h a little hard to understand.
  38.  
  39. It is not enough to just #include whatever headers are in some
  40. implementation.  If your code actually uses any of the stuff associated
  41. with non-standard headers, you better supply some definition of how
  42. _other_ implementations can see the same code and do the "right" thing.
  43.  
  44. Since different implementations will have different definitions of the
  45. non-standard `extensions', you will perhaps find this exercise worse
  46. than frustrating.
  47.  
  48. > *  Defines one or more of these symbols, for use in any non-portable
  49. > *  code:
  50.  
  51. You are missing many other common systems.  Check the code for one that
  52. is missing (__GCC__) and you will find many of the useful ones that you
  53. have omitted.
  54.  
  55. >#if (defined (__TURBOC__))              /*  Borland Turbo-C uses this        */
  56. >#   include <alloc.h>                   /*    name for its include file      */
  57. >#else
  58. >#   include <malloc.h>
  59. >#endif
  60.  
  61. The above is a poor idea.  There are several reasons.  One is that
  62. Borland has long supplied a malloc.h and alloc.h.  Check the contents of
  63. these.  You will find that Borland's malloc.h includes alloc.h itself.
  64. Now, if you have included stdlib.h and stddef.h, you will not need
  65. malloc.h (or alloc.h) for any of NULL, ptrdiff_t, calloc(), free(),
  66. malloc(), or realloc().
  67.  
  68. Unless you are handling legacy code, there is no reason to use
  69. malloc.h/alloc.h for any of the dangerous functions brk or sbrk.
  70.  
  71. If you code has a prayer of portability you should not want -- and with
  72. adequate care or the right tools you will not need -- any of headcheck,
  73. heapfillfree, heapcheckfree, coreleft, _memavl() heapchecknode,
  74. heapwalk,
  75. or the abominatitions of the far versions [far*(), _f*()], huge versions
  76. [h*()] or near versions [_n*()] of the various standard and non-standard
  77. functions here.
  78.  
  79. Nor will you need the struct [far]heapinfo.
  80.  
  81. So just
  82.     #include <stdlib.h>
  83.     #include <stddef.h>
  84.  
  85. And forget the malicious jokes <malloc.h> and <alloc.h>.
  86.                                   
  87. --
  88. * Martin Ambuhl       net: mambuhl@ripco.com
  89. * Chicago, IL (USA)    
  90.